本篇是最後五天方法回顧的第二篇。

本篇要回答：工程事故的最低證據保存清單長什麼樣？為什麼「事後再收集」通常來不及？

當時發生了什麼——五個故事的證據帳單

回顧五案的調查過程，每一次的轉折點都是某份證據就位：故事一是把提問清單攤開分欄；故事二是 sys.executable 的並排；故事三是 repr 與 type；故事四是事故前後的 SQL 對照——以及一次反面教材：Day 17 想寫復盤時，diff 已經散失。故事五是把每層收據的效力邊界列成表。

證據的共同性質：它們在事故當下唾手可得，在三個月後幾乎不可再得。環境會被重裝、分支會被清理、log 會輪替、記憶會被事後理解重寫。保存的時間窗只有現場那一小段。

最低證據保存清單

四個分類，對應四種最常散失的現場：

問題與決策：原始需求、預期結果、驗收條件、假設與限制、決策內容與負責人。（故事一的教訓：沒寫下來的預期結果，事後人人各有版本。）

程式與工具：原始程式碼、Git Diff、工具版本與設定、執行命令、Exit Code、Stack Trace、Log。（故事三、四的教訓：diff 與規則編號是機制歸因的唯一物證。）

環境：OS、Python、套件與 interpreter 路徑、PATH、環境變數、工作目錄、IDE 與 Terminal 設定。（故事二的教訓：環境資訊不隨測試結果保存，矛盾就無從解釋。）

系統事件：Request／Message／Command ID、時間戳記、中間狀態、外部效果、逾時與重試與取消紀錄。（故事五的教訓：沒有貫穿 ID，跨元件對帳只能靠時間戳猜。）

外加一欄經常被忘記的：尚未執行或無法確認的項目。「我們沒查過這個」本身是重要證據——它劃出結論的效力邊界，防止調查報告自己也犯擴張解讀。

為什麼是「最低」

這份清單的設計原則是十分鐘內可完成：commit 或 stash 一次、把幾條指令的輸出貼進事故筆記、截下關鍵 log。成本刻意壓低，因為證據保存輸給「先修再說」的每一次，都是輸在成本感知上——Day 17 已經示範過輸掉的代價：一次昂貴的學習，只剩不可對質的印象。

本篇結論

記憶可以提供調查方向，但只有保留下來的現場狀態，才能支持工程結論。

下一篇（Day 28）把保存下來的證據串起來：從需求到外部效果，畫出一條可以被驗證的事件軌跡。